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(54) Data link layer quality of service for UMTS 

(57) A Data Link Layer (DLL) (20) protocol for direct 
support of the Internet Protocol (IP) networking in the 
Universal Mobile Telecommunications System (UMTS) 
(100), is provided. The disclosed Data Link Layer (20) 
comprises a Radio Link Control (RLC) (70) sublayer and 
a Medium Access Control (MAC) (80) sublayer. At a 
transmit end, as well as at a receiving end of the UMTS 
wireless system (100), a plurality of Quality of Service 
(QoS) planes (1...n) are created according to IP QoS 
requirements. At the RLC level, each QoS plane (1...n) 

comprises a Data-RLC (14-1 14-n) and a Control- 

RLC (12-1 12-n). The QoS planes (1...n) are opti- 
mized to handle the QoS requirements of a correspond- 
ing Class of Service (CoS). At the transmitting end. the 
data packets received from the upper layers are 
directed to a QoS plane according to the particular QoS 
information they contain, and processed according to 
their particular QoS requirement. A Segmentation, Con- 
catenation, and Reframing module (SCR) is used to 
generate variable size RLC frames (77; 77'), including 
multiframing. The variable size RLC frames (77; 77}are 
transmitted to the MAC sublayer (80) using logical chan- 
nels (15). At the MAC sublayer (80). the RLC frames 
(77; 77') are multiplexed onto transport channels (25) 
based on their QoS requirements and transmitted to the 
physical layer for propagation to the receiving end. 
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Description 

BACKGROUND OF THE INVENTION 

Field of the Invention s 

[0001 J The present invention relates generally to 
Data Link Layer (DLL) protocols, and more particularly 
to a DLL protocol for direct support of network layer pro- 
tocol data services, i.e. the Internet Protocol (IP), for the 10 
Universal Mobile Telecommunications System (UMTS). 

Description of the Related Art 

[0002] Layered architecture is a form of hierarchical is 
modularity used in data network design. All major 
emerging communication network technologies rest on 
the Open System Interconnections (OS I) layer architec- 
ture of the International Organization for Standardiza- 
tion (ISO), illustrated in Figure 1. In this architecture, a 20 
layer performs a category of functions or services. The 
OSI model defines a Physical Layer (Layer 1) which 
specifies the standards for the transmission medium, a 
Data Link Layer (Layer 2), a Network Layer (Layer 3), a 
Transport Layer (Layer 4) and Application Layers (Lay- 25 
ers 5 to 7). Data Link Control protocols are used to mit- 
igate the effects of impairments introduced by the 
physical transmission medium. A Data Link Control pro- 
tocol is designed to deal specifically with the types of 
impairments found on the radio link and comprises so 
mechanisms to deal with errors on the communications 
link, delays encountered in transmitting information, lost 
information, bandwidth conservation, and contention 
resolution. 

[0003] The third layer is the Network Layer which 35 
implements routing and flow control for the network. 
[0004] The fourth layer, Transport Layer, provides 
reliable and transparent transfer of data between end 
points, h also provides end-to-end error recovery and 
flow control. For the Internet based protocol model, the 40 
Transport Control Protocol (TCP) mainly corresponds to 
the Transport Layer of the OSI model. 
[0005] Current wireless networks use layer 2-4 pro- 
tocols designed specifically for the wired networks. 
However, there are some major differences between the 45 
wireless and the wired environment, resulting in impor- 
tant differences in the way these networks operate. 
[0006] In a wired network the bit error rates are typ- 
ically on the order of 10" 9 or better, and errors and 
packet loss have a tendency to be random. Therefore, so 
the wired transmission medium could be considered 
essentially error-free and the TCP data packets are lost 
mainly due to congestion in the intervening routers. 
Moreover, in a wired system the transmission channel 
has a constant bandwidth and is symmetrical, which ss 
means the characteristics of the channel in one direc- 
tion can be deduced by looking at the characteristics of 
the channel in the other direction. Therefore, it is often 
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easier to use a common link control protocols and to 
solve congestion problems by adding bandwidth. 
[0007] On the other hand, in a wireless environ- 
ment, most of these assumptions are no longer valid. 
The wireless channel is characterized by a high bit error 
rate. The errors occur in bursts that can affect a number 
of successive packets. Due to fading, low transmission- 
power available to the User Equipment (UE), or the 
mobile station, and effects of interference, the radio link 
is not symmetrical and the bandwidth of a transmission 
channel rapidly fluctuates over time. 
[0008] Furthermore, in a wireless environment, the 
amount of bandwidth available to the system is fixed 
and scarce. Adding bandwidth to the radio link may be 
expensive or even impossible due to regulatory con- 
straints. 

[0009] In addition, the issues in connection with 
increasing the transmission bandwidth are substantially 
different in the wireless environment. In a wir ecj. environ- 
ment increasing the throughput is. simply a matter of " 
allocating as much bandwidth as possible to the con- 
nection. In a wireless environment, part of the band- 
width is used in error correction. More error correction 
means less pay load. However, more error correction 
increases the probability of correct delivery without., 
retransmissions. Thus, in the wireless environment 
increasing the end-to-end throughput may be obtained ' 
by reducing bandwidth assigned to payioad and using 
the freed bandwidth for error correction. 
[0010] The Data Link Layer (DLL) protocols availa; 
ble to date for wireless systems do not attempt to be 
inclusive as complete DLL protocol* Basically, -off-the : 
sheff protocols intended for different media have been 
adopted for wireless systems.. Even though some of 
those protocols are standardized, they are not veryeffi- 
cient for the wireless system. Also, some of the interac- 
tions between the non-wireless protocols and the 
communication system have caused a lot of complexi- 
ties. For example, a point to point protocol (PPP) is cur- 
rently used to conduct part of the functionality needed 
for the Data Link Layer (DLL). However, such a protocol 
imposes new limitations over the communication sys- 
tem. Moreover, for the DLL protocol to support the IP 
quality of service (IPQoS), the PPP encapsulation must 
be undone and this lowers the throughput. 
[001 1 ] Accordingly, there is a need for a specialized 
DLL protocol for a 3G wireless system which can satisfy - 
the demand for advanced multimedia services in a 
UMTS environment, to support multiple concurrent 
voice, packet data, and circuit data services, each type 
of service having different QoS requirements. 

SUMMARY OF THE INVENTION 

[0012] According to one aspect of the invention a 
Data Link Layer (DLL) for direct support of a network 
layer protocol is provided. At a transmit end, as well as 
at the receiving end of a wireless communication sys- 
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tern, the DLL of the invention uses a plurality of QoS 
planes for processing the received data packets accord- 
ing to a particular QoS requirement. A QoS plane is 
comprised of a Data-RLC and a Control-RLC Accord- 
ing to the information in a received network layer data 5 
packet, a subflow processing module converts the 
received data packets into QoS oriented data packets 
and redirects same to the appropriate QoS plane. Each 
QoS plane or subflow, includes a segmentation, con- 
catenation and refraining (SCR) module for generating w 
radio link protocol data units (RLC PDUs), or RLC 
frames to be multiplexed and transmitted to the receiv- 
ing end. 

[001 3] According to another aspect of the invention, 
a method for processing network layer protocol data is 
packets for transmission over the UMTS wireless com- 
munication system, is provided. At a transmit end, as 
well as at the receiving end of the UMTS wireless sys- 
tem a plurality of QoS planes are created at the Radio 
Link Control (RLC) level of the wireless communication so 
system for processing the data packets received from 
the network layers according to their QoS requirements, 
and to generate RLC frames be multiplexed and trans- 
mitted over the Physical Layer. The method comprises 
the steps of converting the received network layer proto- 25 
col data packets into QoS oriented data packets accord- 
ing to the information contained in the received data 
packets; directing the QoS oriented data packets to a 
corresponding QoS plane, each QoS plane having its 
dedicated Data-RLC and Control-RLC instances, as 30 
well as Radio Resources Control; at the RLC level, 
dividing the QoS oriented data packets in smaller size 
sequence frames and reassembling a plurality of 
sequence frames to form RLC frames; at the MAC level, 
receiving the RLC frames, multiplexing, and regulating 35 
their delivery to the physical layer over transport chan- 
nels. 

[001 4] According to another aspect of the invention, 
a method for processing network layer protocol data 
packets fa transmission over a wireless communication 40 
system is provided. A plurality of QoS data planes are 
created at the Data Link Layer level of the wireless com- 
munication system for processing the data packets 
received from the network layers according to a Class of 
Service (CoS). and to generate RLP PDUs to be trans- 45 
mitted over the Physical Layer. The method comprises 
the steps of converting the received network layer proto- 
col data packets into QoS oriented data packets accord- 
ing to the information contained in the received data 
packets; directing the QoS oriented data packets to an so 
appropriate QoS data plane, each QoS data plane hav- 
ing its dedicated LAC and MAC instances; at the LAC 
level, dividing the QoS oriented data packets in smaller 
size sequence frames and encapsulating a plurality of 
sequence frames to form HDLC-tike LAC frames; at the ss 
MAC level, receiving the LAC frames and regulating 
their delivery to the radio link protocols (RLPs) and con- 
verting the LAC frames into protocol data units (RLP 



PDUs). 

[001 5] Advantageously, the Data Link Layer accord- 
ing to the invention, enables direct support of the IP net- 
working and IP Quality of Service (IP QoS) in the 
wireless UMTS system by introducing the QoS planes 
to handle different QoS requirements demanded by var- 
ious advanced multimedia services. 
[0016] The Data Link Layer according to the 
present invention removes the need for other non-wire- 
less data link protocols, such as PPP. to connect to the 
IP. 

[0017] Beneficially, a Radio Link Control (RLC) sub- 
layer supported by the preferred embodiments of the 
present invention is capable of interfacing with existing 
non-wireless Data Link protocols. 
[0018] Other aspects and features of the present 
invention will become apparent to those skilled in the art 
upon review of the following description of specific 
embodiments of the invention in conjunction with the 
accompanying figures. 

[001 9] The Summary of the Invention does not nec- 
essarily disclose all the features essential for defining 
the invention; the invention may reside in a sub-combi- 
nation of the disclosed features. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0020] The invention will now be explained by way 
of example only and with reference to the drawings. 

Figure 1 A shows the OSI layers in general; 
Figure 1 B is a sequential timing chart for the trans- 
mission operation according to a convehtional^rtQ 
protocol; .. . — 

Figure 1 C is a transmission frame structure acco*^ 
injg to thecooyentional ARG protocol; 
Figure 2 shows the OSI layer* for a wireless com- 
munication system according to the proposecLIlA 
TR-45.5; • +\ 

Figure 3 is a block diagram of the DLC protocor 
according to a preferred embodiment of the inven- 
tion; 

Figure 4 illustrates the mapping of the IP packets to 
RLP PDUs (frames) according to a preferred 
embodiment of the invention 
Figure 5 illustrates the mode of operation of an 
improved dual mode Layer 2 ARQ protocol; 
Figure 6 shows the radio interface protocol archi- 
tecture used with UMTS; 

Figure 7 is a block diagram of the Data Link Layer 
(DLL) protocol according to a preferred embodi- 
ment of the invention; and 
Figure 8 illustrates the mapping of IP packets to 
RLC PDUs (RLC frames) according to a preferred 
embodiment of the invention. 

[0021] Similar references are used in different fig- 
ures to denote similar components. 
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DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0022] The following description is of a preferred 
embodiment by way of example only and without limita- s 
Won to the combination of features necessary for carry- 
ing the invention into effect. 

[0023] Throughout the description the term "Quality 
of Service" (QoS) refers to network layer protocol QoS 
which includes "best effort", "expedited delivery", and w 
"assured delivery". A Class of Service (CoS) defined at 
the DLC layer includes a set of services that have sub- 
stantially the same QoS requirements. 
[0024] Figure 1 A shows the International Organiza- 
tion for Standardization (ISO/OSI) reference model in is 
general, and was described above. The layers are 
denoted with 20 (not shown), 30, 40, 50 and 60. 
[0025] Ftgure 1 B shows a typical data transmission, 
using Automatic Repeat Request (ARQ), and Figure TC 
shows a transmission frame structure for a conventional 20 
ARQ system. Figure 1B illustrates a transmitter Tx on 
the transmitting side of a wireless transmission system, 
a receiver Rx on the receiving side, and the transmis- 
sion path. The transmission path is a wireless transmis- 
sion channel established between the transmitting and 25 
receiving sides. 

[0026] The ARQ frame 10 of Figure 1C comprises 
client information, denoted "information signal" 12, 
which is the data to be transmitted. An error detection 
code 1 3, such as a Cyclic Redundancy Checking (CRC) 30 
code is attached to the transmission data 12 by the 
ARQ transmitter Tx. At the ARQ receiver Rx, each 
frame 10 of the received signal is checked for errors 
using field 13, and Rx sends a re-transmission request 
signal back to Tx whenever an error is detected. In the 35 
case the frame is received without errors, Rx extracts 
the information signal 12 from frame 10 and the client 
information is delivered to the respective terminal. 
[0027] Field 11 denotes "ARQ control data" in 
frame 10 indicates to Tx rf the data have arrived at Rx 40 
with or without errors, and also identifies which frame 
has to be retransmitted. 

[0028] Figure 1B illustrates transmission of eight 
consecutive frames, frame 1 to frame 8. In this example, 
frame 1 is received correctly by Rx, which sends Ack #1 45 
(Acknowledgment frame #1) to Tx. On the other hand, 
frame 2 is received with errors, and Rx sends NAK #2 
(Negative Acknowledgment, frame #2) to Tx, which indi- 
cates that frame 2 must be retransmitted. In response to 
this NAK #2 signal, Tx retransmits frame 2, denoted so 
with 2' on Figure 1B. Nak #2 is received during trans- 
mission of frame 4 so that the second frame 2' is 
retransmitted immediately after frame 4 and before 
frame 5. If frame 2' is again received in error, retrans- 
mission is requested again, in response to the NAK #2' ss 
signal, until frame 2 is received without errors, as indi- 
cated to Tx by Ack #2 signal. 
[0029] Current second generation (2G) wireless 
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systems are designed mostly to handle voice traffic, 
with some allowances for circuit-switched data. Later, 
packet data services were grafted onto the 2G systems 
but these are uniformly treated according to "best effort 
delivery" schemes. The type of RLP used in 2G sys- 
tems is typically based on the generic service(s) availa- 
ble to the MS (Mobile Station), as for example voice 
services, packet data services, and/or circuit switched 
data services. The voice service may use a transparent 
RLP which does not provide error detection. The packet 
data service may use a non-transparent RLP which pro- 
vides error detection and retransmissions. The circuit 
switched data service may use either a transparent or a 
non-transparent RLP. 

[0030] Enhancements to the existing 2G wireless 
systems are currently under way, motivated by higher 
bandwidth and the need to handle a wider variety of 
services. Proposed standard TIA TR-45.5 supports ay 
fully generalized multi-media service model, which 
allows virtually any combination of voice, packet data, * 
and high speed circuit data services to operate concur- 
rently. The TIA TR-45.5 wilt include a sophisticated. 
Quality of Service (QoS) control mechanism to balance" • 
the varying QoS requirements of multiple concurrent 
Classes of Service (CoS). 

[0031] Non-wireless Data Link Layer protocols(e.g. 
PPP). Network Layer protocols (e.g. IP). Transport 
Layer protocols (e.g. TCP), and the Application Layers 
are considered as "upper layer protocols" in the wireless 
protocol stack architecture, shown in Figure 1 A. 
[0032] In the third generation (3G) wireless commu- 
nication systems, the Internet Protocol (IP) is selected 
as the preferred network layer protocoJ 41 . 
[0033] The IP packets (e.g. versions 4 and 6) 
include the IP Quality of Service (IPQoS) information. " 
There are two main trends in the industry to support the 
IP QoS. The first method uses an end-to-end flow con- 
trol. This method is called the Integrated Services (Int- 
Serv), and it uses a Reservation setup Protocol 
(RSVP) to pass the QoS request from the end system to 
each intermediate router along the data path. An admis- 
sion control algorithm at each router along the path ver- 
ifies the resources needed to provide the requested 
QoS. A policy control unit performs the administration. 
The Int-Serv approach results in lowering the through- 
put and it is somewhat complicated and not easily scal- 
able. In the second method, the complexity is moved-to 
the edges of the network, keeping the core simple. This 
scheme is named Differentiated Services (Diff-Serv). 
The traffic conditioning is done in a per-hop basis. The 
Diff-Serv method is preferred as it is easy to implement 
and scalable. 

[0034] The Data Link Layer protocols proposed to 
date for the TIA TR-45.5 do not support IP 41 directly 
and therefore, other protocols such as PPP 42 are 
used, as shown in Figure 2. Obviously, these protocols 
impose additional restrictions on the wireless system in 
general. 
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[0035] Figure 3 shows the structure of the DLC 
layer 100 according to a preferred embodiment of the 
invention, which is designed to support IP networking 
without adding any limitations that are not related to the 
wireless systems. The new DLC layer 100 design 
according to the preferred embodiment of the invention 
may be viewed as an interface between the IP layer 41 
and the Physical Layer 20 (not shown), and can accom- 
modate a variety of Classes ol Service (CoS) having dif- 
ferent Quality of Service (QoS) requirements. It follows 
that the layers proposed in the ITU IMT-2000, i.e. the 
DLC layer functionality is divided into LAC sublayer 70, 
and MAC sublayer 80 which in turn includes the PLDCF 
and the PLICF sections. 

[0036] The DLC protocol 100 according to the pre- 
ferred embodiment of the invention is shown in Figure 3 
and includes direct support for the IP protocol 41 and 
isolates the logical operation of the network from the 
Physical Layer 20 (not shown). As indicated above, the 
IP packets include the IP Quality of Service (IPQoS) 
information. The DLC layer 100 has a scheme to map 
the IPQoS requirements to DLC Classes of Service 
(CoS). Each CoS is separated inside the DLC protocol 
layer 100 and directed to a specific QoS data plane. 
[0037] Figure 3 shows the structure of an enhanced 
DLC protocol architecture 100 according to the pre- 
ferred embodiment of the invention, for two QoS data 
planes, namely QoS data plane 1 and QoS data plane 
2, separated by a dotted line. It is however to be under- 
stood that the invention is not limited to two QoS data 
planes, and that more planes may run simultaneously in 
the DLC layer 30. Each QoS data plane is optimized to 
handle the QoS requirements of the corresponding 
CoS. 

[0038] Figure 4 illustrates how the data is proc- 
essed in the DLC protocol layer 100 and is described 
together with Figure 3. 

[0039] A QoS processing module 71 of the LAC 
layer 70 is responsible for receiving the IP packets and 
extracting the IP QoS requirements included in the IP 
packets. IP QoS requirements are translated into QoS 
classes of service. The QoS processing module 71 also 
initiates a QoS data plane for each CoS through a 
Resource Control (RC) unit 74. Each QoS data plane 
include dedicated LAC and MAC instances. 
[0040] An IP packet received by the QoS process- 
ing module 71 directly from IP block 41 of network layer 
40 (shown in Figure 2), is denoted with 45. An optional 
length (LEN) indicator 47 is added to each packet 45 by 
the QoS processing module 71 . The length indicator 47 
is added to enable reconstruction of the original IP 
packet 45 by a Segmentation and Reassembly (SAR) 
module (not shown) at the receiving side. Similarly, the 
length indicator of the IP header can be used. In this 
case, the LEN indicator is not needed. The resulting 
packet 46 is called an "augmented IP packet". 
[0041] Furthermore, based on the QoS classifica- 
tion obtained, QoS processing module 71 redirects the 



IP packets 45 to the proper QoS data plane. Packets 
without IP QoS classification are defaulted to a "best 
effort" QoS data plane. It should be noted that any net- 
work layer protocol other than the IP may be supported 
5 by including the corresponding functionality in the QoS 
processing module 71. There is at least one QoS 
processing module (not shown) for each Mobile Station 
(MS). Moreover, the receiving and the transmitting sides 
comprise identical QoS data planes, 
to [0042] A Segmentation and Reassembly (SAR) 
modules 72, 72rj is provided in each QoS plane. For 
example. SAR 72 is provided in QoS data plane 1 , and 
SAR 72* is provided in QoS data plane 2. In this exam- 
ple, SARs 72 and 72' receive the redirected and aug- 
75 merited IP packets 46. or QoS oriented data packets 
having same Quality of Service (QoS) requirements. 
[0043] SAR module 72 or 72* chops the augmented 
IP packet 46 to smaller size packets, which are more 
suitable for error recovery and retransmission. These 
20 smaller size packets are defined as "sequence frames", 
denoted with 74. 74'. on Figure 4. The size- of a 
sequence frame is variable and dynamically optimized 
for different QoS data planes based on the QoS require- 
ments and the radio link conditions. 
25 [0044] A start of message (SOM)-bit field 75 and a 
sequence number field 76 are then added to the pay- . 
load 46. A logic T for example in SOM bit 75 could be 
used to identify the start of a sequence frame 74. while 
the sequence number is necessary in the retransmis- 
30 sions of unsuccessful frames. 

[0045] As a result, a number of smaller same Class 
of Service (CoS) sequence frames 74. 74', are pre- 
sented by a respective SAR module 72, 72*. to a Fram- . 
ing and Automatic Repeat Request (ARQ) module 73, . 
35 73*. A new level of error recovery (i.e. ARQ) is created at 
the LAC level to provide better connectivity and to pre- 
vent propagation of errors to higher levels. The 
sequence frames are then encapsulated in High-level 
Data Link Control (HDLC)-like frames 77, 77', in a 
40 respective Framing and ARQ module 73. 73*. 

[0046] HDLC-like framing is used to separate indi- 
vidual sequence frames by means of "bit stuffing" oper- 
ation within the payload and encapsulating by start and 
end flags. A 16 bit Frame Check Sequence (FCS) 79 is 
45 included for error detection and is used for ARQ proto- 
cols. The HDLC-like framing applied here does not use 
the address and control fields of the generic HDLC 
frames. The HDLC-like frames serve. as LAC Protocol ; 
Data Units (LAC-PDUs), or LAC frames, as indicated on 
so Figure 4. The maximum size of a LAC frame 77 is" 
defaulted to be the same as the one for PPP. which is 
1500 bytes. This maximum value is negotiable. 
[0047] As discussed above, the sequence frame 
74, 74'. has variable length which can be dynamically 
55 adjusted by the transmitting side, based on the radio link 
conditions. This results in variable length LAC-PDUs. 
[0048] The radio link conditions can be monitored in 
the following ways. If there are many negative acknowl- 



5 



9 



EP1 030 4S4A2 



10 



edgments (NAKs) from the receiving side, or for a pre- 
determined period of time no acknowledgment is 
received, then the LAC-PDU size could be lowered to 
enhance the error correction and the overall throughput. 
No negotiations take place between the transmitting 5 
and the receiving LAC instances and therefore, there is 
no need for over the air signalling. 
[0049J The LAC-PDUs 77 are then delivered to the 
MAC instance 80 in the same QoS data plane. The 
point-to-point link connectivity of each QoS data plane w 
is maintained by peer LAC instances at the transmitting 
and the receiving sides. 

[0050] According to the invention, the IP layer 41 
can sit on top of the new DLC layer 100 and the DLC 
protocol provides direct support for any network layer is 
protocol with no need for any other protocol as an inter- 
face. This greatly reduces the limitations imposed by 
other protocols, which are not designed for the wireless 
systems. 

[0051] Within each QoS plane. MAC sublayer 80 so 
comprises the PLICF and PLDCF sections, as per TIA 
TR-45.5. A Dedicated/Common Router (DCR) 81 or 8V. 
is controlled by the MAC Control State Machine (MAC 
CSM) 83, 83' to route LAC-PDUs to be carried over a 
dedicated or a common radio traffic channel. When a 25 
dedicated radio traffic channel is used, the PLDCF sec- 
tion includes a dedicated Radio Link Protocol (RLP) 82 
or 82'. as defined in TIA TR-45,5. The RLP 82 or 82'. 
treats the incoming traffic from the DCR 81, or 8V as a 
byte stream and encapsulates the LAC-PDUs into 20 30 
ms RLP-PDUs. 

[0052] For the non-transparent RLP (as defined in 
the TIA TR-45.5 and the TIA/EIA/IS-707A), ARQ func- 
tion is also provided at the MAC level. The RLP-PDUs 
which are received with errors will be retransmitted. The 35 
functions of the peer RLPs at the receiving side include 
the re-sequencing of the received PDUs to insure in- 
order-delivery to the MS/LAC sublayer. The RLPs used 
are designed for different classes of service (CoS). This 
adds another level of error correction and flexibility for to 
optimizing a QoS data plane for a specific CoS. 
[0053] A preferred embodiment of the present 
invention also provides an improved ARQ protocol at 
the MAC level with two modes of operations: a normal- 
mode (NM) and a burst-mode (BM). When in normal- 45 
mode, a Selective Repeat (SR) ARQ scheme is used. In 
burst-mode, a Stop-and-Wait (SW) ARQ scheme is 
used. Depending on the CoS or the QoS requirements, 
the ARQ protocol chooses to use either one of the SR or 
SW schemes, 50 
[0054] The S R scheme provides highest throughput 
efficiency since the transmitter transmits frames contin- 
uously and only the corrupted frames are retransmitted. 
However, to operate in SR mode, an initialization hand- 
shake procedure is needed so that peer ARQ protocol 55 
entities are initialized, i.e. the frame sequence number 
is reset to zero, and the retransmissions buffer is 
cleared. The latency and bandwidth overhead intro- 



duced by the initialization procedures are undesirable if, 
for example, the traffic profile of the service consists of 
short data bursts with large inter-arrival time and conse- 
quently, the peer RLP entities need to be re-initialized 
after each idle period. 

[0055] The SW scheme is used for short and infre- 
quent data bursts. For the SW scheme, the transmitter 
stops and waits for acknowledgment from the receiver 
before sending out the next PDU. There is no need to 
synchronize the state between peer ARQ protocol enti- 
ties. Therefore, when the SW scheme is used, no initial- 
ization procedures are needed as in the SR case, which 
reduces the associated latency. 
[0056] As shown in Figure 5, a RLP entity is operat- 
ing in one of the two modes, i.e.. normal-mode and. 
burst-mode. When the RLP entity is first activated, it 
transits from the NULL state to a default mode which is 
the burst-mode as shown at 91, where no initialization 
handshake is required. It should be noted that RLP pro- 
tocols are provided in pairs, one at each end of the com- ■ 
munication link. 

[0057] The RLP protocol transits to the normal- ^ 
mode as shown at 92. when certain implementation 
specific conditions are met. One example of such condi- 
tions is when the pending data size is greater than a 
specific threshold. It is to be understood that other con- 
ditions for transition from burst-mode to normal-mode 
may be imposed, according to the respective CoS. 
[0058] Whenever the RLP protocol entity at on«n£. 
decides to transit to the normal-mode, it starts an initial- 
ization handshake procedure. Once the handshake pro- 
cedure is completed, peer RLP protocol entities (the 
paired RLPs) enter in the normal-mode of operation. 
Therefore, the transition is automatically synchronized 
between peer RLP protocol entities. 
[0059] During the initialization handshake process, 
burst-mode operation is not allowed. For unacknowl- 
edged data burst sent out prior to the initialization hand- 
shake process, the RLP protocol entity resends the data 
burst after entering the normal-mode. Any data burst 
received during the initialization handshake process isv ; 
discarded by the ARQ protocol entity. 
[0060] Once in the normal-mode, the RLP protocol V 
entity is not allowed to transit back to the burst-mode, * ; 
since the peer protocol entity at the other end of the, 
communication link is already synchronized. 
[0061] When the RLP instance is released due to " 
the MAC state machine transition to "dormant state", • 
the RLP protocol is deactivated from both modes as 
shown at 93 and 94. 

[0062] We should also note that other APQ mefh- . 
ods may be used in the QoS data plane as defined by 
the present invention for optimizing the operation of the 
QoS data planes. 

[0063] The PLDCF section contains the MUX&QoS 
module 34 which multiplexes various CoS RLP frames 
onto different physical channels. Based on their QoS 
requirements, MUX&QoS 34 transmits multiple service 
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type frames to the Physical Layer 20 (not shown) for 
Coding and Modulation (C&M). 
[0064] The above description was made for the for- 
ward direction of transmission, i.e. from the transmitting 
side to the receiving side. It is to be understood that the 
operations are similar for the reverse direction. 
[0065] At the receiving side, peer SAR modules 
(not shown) perform reassembly of the multiple Class of 
Service (CoS) frames received from a peer dedicated/ 
common router (DCR) module (not shown). 

Data Link Laver for UMTS 

[0066] A wireless communication system has to 
support a packet switched data in a circuit switched 
environment. Previously, for DLL protocols, packet data 
sessions were defined based on different application 
sessions and resources were assigned to each of them. 
According to a preferred embodiment of the present 
invention the incoming traffic is considered a combina- 
tion of different IP flows with different QoS requirements 
(or Classes), called subflows. Thus, the packet data 
application sessions/flows is replaced with QoS sub- 
flows. Irrespective of the application which generated 
the IP flow, the flow is categorized based on the QoS 
requirements, or the CoS. 

[0067] It is to be noted that prior art methods have 
to undo all the higher layers framing and to duplicate all 
the QoS classifications done at the higher layers in 
order to differentiate among different applications, and 
this is contrary to the layering scheme strategy 
[0068] Figure 6 shows the UMTS radio interface 
protocol architecture layer proposed for a 3G wireless 
network and is reproduced from the Third Generation 
Partnership Proposal Technical Specification 25.301 
(3GPP TS 25.301). 

[0069] Layer-1, or the Physical Layer 20 of the 
UMTS radio interface is responsible for coding and 
modulation of data transmitted over the air. 
[0070] Layer -2. or the Data Link Layer 30 is subdi- 
vided into a Radio Unk Control (RLC) sublayer 70 and 
the Medium Access Control (MAC) sublayer 80. The 
separation in MAC 80 and RLC 70 sublayers is moti- 
vated by the need to support a wide range of upper layer 
services, and also the requirement to provide high effi- 
ciency and low latency data services over a wide per- 
formance range, i.e. from 1 .2 Kbps to greater than 2 
Mbps. Other motivators are the need for supporting high 
QoS delivery of circuit and packet data services, such 
as limitations on acceptable delays and/or data BER (bit 
error rate), and the growing demand for advanced mul- 
timedia services. Each multimedia service has different 
QoS requirements. Data Link Layer 30 also comprises a 
C-Plane Signalling and a U-Plane Information for sepa- 
rating the information from control signals. 
[0071] The RLC 70 of the radio interface protocol 
architecture 100 for the UMTS shown in Figure 6, 
receives data packets from the higher layers, such as IP, 



through Service Access Points (SAP) 13. and delivers 
RLC frames to the MAC sublayer 80. The RLC frames 
are queued into logical channels 15. At the MAC sub- 
layer 80. the RLC frames are multiplexed onto transport 
5 channels 25. The transport channels 25 are the inter- 
face of the Physical Layer 20 to the Data Link Layer 30. 
In fact. Data Link Layer 30 functions are divided in two 
parts, Physical Layer Independent Convergence Func- 
tion (PLICF) handled in the RLC 70. and Physical Layer 
lo Dependent Convergence Function (PLDCF) included in * 
the MAC 80. It is assumed that there is one instance of 
RLC 70 for each data application/session. 
[0072] Figure 7 illustrates the DLL protocol accord- 
ing to a preferred embodiment of the invention which 
is includes direct support for the IP protocol and isolates 
the logical operation of the Network Layers from the 
Physical Layer 20. The structure of the Data Link Layer 
30 shown in Figure 7. is designed to support IP net- 
working without adding any limitations that are not 
20 related to the wireless systems. The new Data Link 
Layer 30 design may be viewed as an interface between 
the IP layer and the Physical Layer 20, and can accom- 
modate a variety of Classes of Service (CoS) having drf- .. 
ferent Quality of Service (QoS) requirements. 
25 [0073] As indicated before, the IP packets 45- . 
include the IP Quality of Service (IPQoS) information. 
The DLL protocol 100 has a scheme to map the IPQoS 
requirements to Classes of Service (CoS). Each CoS is 
separated inside the DLL 30 and directed to a dedicated 
30 QoS plane. 

[0074] The architecture of Figure 7, comprises a 
subflow processing module 71 for receiving the IP pack- 
ets through check point 11 and redirecting the IP pack- 
ets 45 to different instances of the QoS planes (1...n). 
35 The subflow processing module 71 checks the IP pack- 
ets 45 and categorizes them into different subflows. "or 
equivalents QoS planes (1„.n). For example, if the 
Duff-Serv method is used, the subflow processing mod- 
ule 71 may simply peak into the IP packets 45 to map 
40 the QoS requirements, or CoS included in the IP packet : 
45 to one of the QoS planes (l...n) in the RLC 70. If the 
Int-Serv is used, the subflow processing module 71 
involves in the RSVP, or any admission protocol, and" 
redirects each IP packet 45 to one of the QoS planes 
45 (1...n) based on the agreed QoS requirements. It is to 
be noted that there is one dedicated subflow processing 
module 71 for each User Equipment (UE). 
[0075] Each QoS plane (L.n) is configured to han- 
dle a CoS or equivalent^ a range of QoS requirements: . 
so Each QoS plane (1.. n) includes a Data-RLCs (D-RLC) 
(14-1 ... 14-n) and its associated Control-RLCs (C-RLC) 
(12-1. ..12-n). As shown before, the D-RLCs (14-1. ..14r 
n) and C-RLCs (12-1 ...12-n) receive the IP data packets 
45. create the RLC PDUs. or RLC frames and deliver 
55 the RCL frames over logical channels 15 to the MAC 
sublayer 80 to be multiplexed onto different transport 
channels 25. 

[0076] The inclusion of an associated Control-RLC 
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12 is necessary because data are handled based on 
their QoS requirements and consequently, the associ- 
ated control signals must be treated at least the same to 
meet those requirements. For example, it is not accept- 
able to send control signals associated with a higher pri- 
ority to propagate data with a lower priority traffic. This 
may result in violation of proper treatment of the QoS 
requirements corresponding to the transmitted data. 
Still, increasing the priority of the Control-RLC 12 to 
indirectly increase the priority of associated data, is per- 
mitted. This is especially important in the case where 
control signals are needed to insure connectivity, 
although the data might be sent as in the best effort 
delivery. 

[0077] In contrast with the fixed Radio Link Proto- 
cols (RLPs) defined for the "cdma2000" standard, the 
RLCs are totally re-configurable, i.e. the segment size, 
the number of retransmission, etc. Thus, QoS planes 
<1...n) are also reconfigurable to fit a corresponding 
CoS. 

[0078] There are a number of entities inside a QoS 
plane (1...n) that can be dynamically reconfigured, or 
fine tuned and optimized to meet specific QoS require- 
ments of a CoS. This includes, segment size at the Seg- 
mentation, Concatenation and Reassembly (SCR) 
module of the RLC, resource assignments, logical chan- 
nel to transport channel mapping, priorities, etc. Moreo- 
ver, the type of the error recovery method used in each 
QoS plane (l...n) varies and depends on the QoS 
requirements in that particular plane. 
[0079] Figure 8 illustrates the process of mapping 
the received IP packets 45 into RLC PDUs, or RLC 
frames according to the DLL protocol 100. As discussed 
before in connection with Figure 7, the subflow process- 
ing module 71 is responsible for receiving the IP pack- 
ets 45 and extracting the IP QoS requirements included 
in each packet. IP QoS requirements are translated into 
classes of service (CoS) The subflow processing mod- 
ule 71 also initiates a QoS plane (1... n), or subflow, for 
each CoS under the supervision of a Radio Resource 
Control (RRC) unit 44. Each QoS plane (t..n) includes 
dedicated D-RLC and (14-1... 14-n) and C-RLCs (12- 
1...l2-n) instances. 

[0080] Based on the QoS classification obtained, 
the QoS subflow processing module 71 redirects the IP 
packets 45 to the proper QoS plane (1...n). Packets 
without IP QoS classification are defaulted to a "best 
effort" data plane. It should be noted that any network 
layer protocol other than the IP may be supported by 
including the corresponding functionality in the QoS 
subflow processing module 71. There is one corre- 
sponding QoS subflow processing module 71 for each 
User Equipment (UE). Moreover, the receiving and the 
transmitting ends comprise identical QoS planes (1 ...n). 
[0081] The method of generating radio link control 
protocol data units (RLC PDUs), or RLC frames will be 
now discussed in connection with RLC frame 77. As 
shown in Figure 8, an optional length (LEN) indicator 47 
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is added to each IP packet 45 by the subflow processing 
module 71. The length indicator 47 is added to enable 
reconstruction of the original IP packet 45 by a Segmen- 
tation, Concatenation and Reassembly (SCR) module 

5 which is part of the RLC at the receiving side (not 
shown). In the case when the length indicator of the IP 
header is used, the LEN indicator 47 is not needed. In 
any event, the resulting packet 46 is called an "aug- 
mented IP packer. 

io [0082] The SCR module of the D-RLC (14-1. ..14-n) 
chops the augmented IP packet 46 into smaller size 
packets, which are more suitable for error recovery and 
retransmission. These smaller size packets, or 
"sequence frames" are denoted with 74, on Figure 8. 

is The size of a sequence frame 74 may be variable and 
dynamically optimized in different QoS planes (1...n), 
based on the QoS requirements and on the radio link 
conditions. 

[0083] A start of message (SOM) bit field 75 and a 

20 sequence number field 76 are then added to the pay- 
load 46. A logic "1 " for example in SOM bit 75 could be 
used to identify the start of the sequence frame 74. The 
sequence number is necessary in the retransmission of 
unsuccessful frames. 

25 [0084] A QoS field 73 is also added to each 
sequence frame 74 to differentiate various frames 
directed to different QoS planes (1...n). This field is 
denoted as "QoS" in Figure 7, and contains the QoS 
plane number of the frame. This information is neces- 

30 sary for the multiplexing/demultiplexing process per- 
formed between peer Medium Access Control (MAC) 
layers. Specifically, field 73 is needed at the MAC sub- 
layer at the receiving end for redirecting the received 
frames to the proper QoS plane. 

35 [0085] One important feature in the SCR module 
(which is part of the RLC), is the "concatenation" of 
short data messages. In the case where the amount of 
data in each IP packet 45 is very small with respect to 
the size of the RLC PDU 77, i.e. a 10 ms frame load, the 

40 SCR module concatenates a number of short mes- 
sages into one RLC frame 77. This is a subframing 
process performed at the Link Layer 30 level, is called 
"multiframing". 

[0086] A frame check sequence (FCS) 79 and flags 
45 68 and 78 may be added. The RLC frame 77* are then 
delivered to the MAC instances over the logical chan- 
nels 15. 

[0087] The point-to-point link connectivity of each 
QoS plane (1...n) is maintained by peer RLC instances 

so located at both the transmitting and the receiving sides. 
[0088] The RLC Protocol Data Units (RLC-PDUs). 
or RLC frames 77 are delivered to the MAC sublayer 80 
to be multiplexed onto different transport channels 25 
and prioritized based on their QoS requirements. The 

55 Radio Resource Control (RRC) module 44 controls this 
operation. 

[0089] In the receiving side, the MAC sublayer 
demultiplexes the received frames and redirects them to 
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corresponding QoS planes based on their QoS plane 
number field 73. 

[0090] A Data Link Layer (DLL) 20 protocol for 
direct support of the Internet Protocol (IP) networking in 
the Universal Mobile Telecommunications System s 
(UMTS) 100, is provided- The disclosed Data Link Layer 
20 comprises a Radio Link Control (RLC) 70 sublayer 
and a Medium Access Control (MAC) 80 sublayer At a 
transmit end, as well as at a receiving end of the UMTS 
wireless system 100, a plurality of Quality of Service jo 
(QoS) planes l...n are created according to IP QoS 
requirements. At the RLC level, each QoS plane i...n 2. 

comprises a Data-RLC 14-1 14-n and a Control-RLC 

12-1 12-n. The QoS planes 1...n are optimized to 

handle the QoS requirements of a corresponding Class is 
of Service (CoS). At the transmitting end, the data pack- 
ets received from the upper layers are directed to a QoS 
plane according to the particular QoS information they 
contain, and processed according to their particular 
QoS requirement. A Segmentation, Concatenation, and so 
Refraining module (SCR) is used to generate variable 
size RLC frames 77; 77', including multiframing. The 3. 
variable size RLC frames 77; 77' are transmitted to the 
MAC sublayer 80 using logical channels 15. At the MAC 
sublayer 80, the RLC frames 77; 77' are multiplexed 25 
onto transport channels 25 based on their QoS require- 
ments and transmitted to the physical layer for propaga- 
tion to the receiving end. 

[0091] According to the invention, the IP layer can 
sit on top of the new Data Link Layer 20 and the DLL so 
protocol 100 provides direct support for any network 
layer protocol with no need for any additional protocol 
as an interface. This greatly reduces the limitations 
imposed by other protocols, which are not designed for 4. 
the wireless systems. 35 
[0092] The above description was made for the for- 
ward direction of transmission, i.e. from the transmitting 
end to the receiving end. it is to be understood that the 
operations are similar for the reverse direction. 
[0093] Numerous modifications, variations, and *o 
adaptations may be made to the particular embodi- 
ments of the invention described above without depart- 
ing from the scope of the invention defined in its claims. 

5. 

Claims 45 

1. A Data Link Control (DLC) protocol for direct sup- 
port of a network layer protocol, comprising: 6. 

at a transmit end of a wireless communication so 
system: 

a plurality of Quality of Service (QoS) data 
planes, a QoS data plane for processing a 7. 
QoS oriented data packet according to a ss 
class of service (CoS), and to provide a 
radio link protocol data unit (RLP PDU); 
a QoS processing module for receiving a 



network layer protocol data packet, con- 
verting said network layer protocol data 
packet into said QoS oriented data packet, 
and directing said QoS oriented data 
packet to one of said QoS data planes 
according to QoS information in said net- 
work layer protocol data packet: and 
an interface between said DLC and a phys- 
ical layer for receiving said RLP PDU and 
transmitting same to said physical layer. 

A DLC protocol as claimed in claim 1 , wherein each 
said QoS data plane comprises: 

a Link Access Control (LAC) protocol instance 
for receiving said QoS oriented data packet 
and generating a HDLC-like LAC frame; and 
a Medium Access Control (MAC) protocol 
instance for receiving said LAC frame arid gen- 
erating said RLP PDU. 

A DLC protocol as claimed in claim 2, wherein said 
LAC protocol instance comprises: 

a segmentation and re-assembly (SAR) mod- 
ule tor receiving said service oriented data ' 
packet and dividing same into a number of 
sequence frames; and 

a framing and automatic repeat request (ARQ) 
module for receiving said sequence frames, 
and encapsulating a plurality of said sequence 
frames into said LAC frame. 

A DLC protocol as claimed in claim 2 or 3, wherein 
said MAC protocol instance comprises: 

a dedicated/common router (DCR) for receiv- 
ing and routing said LAC frames to be carried 
over a radio traffic channel; and 
a radio link protocol (RLP) for receiving said 
LAC frames and converting said LAC frames 
into said RLP PDUs. 

A DLC protocol as claimed in claim 4, further com- 
prising a MAC control state machine (CSM) for reg- 
ulating the delivery of said LAC frames to said RLP. 

A DLC protocol as claimed in claim 4 or 5. wherein 
said RLP comprises an automatic repeat request 
(ARQ) function for automatic retransmission of said 
RLP PDUs if received in error at a receiving end of 
said wireless system. 

A DLC protocol as claimed in claim 6, wherein said 
ARQ function has a selective repeat component 
active during a normal-mode (NM) of operation and 
a stop and wait (SW) component active during a 
burst-mode (BM) of operation. 
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8. A DLC protocol as claimed in any one of claims 3 to 
7, wherein said LAC frame has a variable size, said 
size being dynamically optimized based on the con- 
ditions of the communication link. 

5 

9. A DLC protocol as claimed in claim 8, wherein said 
size of said LAC frame is automatically reduced: i) 
when a predetermined number of negative 
acknowledgments (NAK) are received, or ii) rf no 
acknowledgments are received for a predetermined w 
period of time. 

10. A DLC protocol as claimed in any preceding claim, 
wherein said interface is a multiplexer for receiving 
said RLP PDU, and multiplexing same into a physi- is 
cal channel according to the QoS of said RLP PDU, 

for transmission to a receiving end of said wireless 
system. 

11. A DLC protocol as claimed in any preceding claim, 20 
further comprising a resource control unit for map- 
ping a QoS requirement to a DLC class of service 
(CoS), and separating said CoS inside the DLC 
protocol into said QoS data planes. 

25 

12. A method for direct processing a network layer pro- 
tocol data packets for transmission over a wireless 
communication system, comprising the steps of: 

separating the data link layer of the wireless 30 
communication system into a plurality of Qual- 
ity of Service (QoS) data planes, a QoS plane 
for processing a QoS oriented data packet 
according to a class of service (CoS), and to 
provide a radio link protocol data unit (RLP 35 
PDU); 

processing said network layer protocol data 
packet by converting said network layer proto- 
col data packet into said QoS oriented data 
packet and directing said QoS oriented data 40 
packet to one of said QoS data planes accord- 
ing to QoS information in said network layer 
protocol data packet; and 
forwarding said RLP PDU to a physical layer 
according to the QoS of said RLP PDU. 45 

13. A method as claimed in claim 14, wherein said step 
of separating comprises: 

providing a plurality of QoS oriented Link so 
Access Control (LAC) protocol instances, a 
LAC protocol instance for each said QoS data 
plane, said LAC protocol instance for receiving 
said service oriented data packet and generat- 
ing a HDLC-like LAC frame; and 55 
providing a plurality of QoS oriented Medium 
Access Control (MAC) protocol instances, a 
MAC protocol instance for each QoS data 



plane, said MAC protocol instance for receiving 
said LAC frames and generating said radio link 
protocol data unit (RLP PDU). 

14. A method as claimed in claim 13. wherein said step 
of generating a HDLC-like LAC frame comprises 
dividing said QoS oriented data packet into a 
number of sequence frames and encapsulating a 
plurality of said sequence frames into said LAC 
frame. 

15. A method as claimed in claim 13 or 14, wherein 
said step of generating said RLP PDU comprises 
receiving said LAC frames and converting said LAC 
frames into said RLP PDUs. 

16. A method as claimed in claim 15, further compris- 
ing regulating the delivery of said LAC frames to 
said RLP. . 

17. A method as claimed in claim 13, 14, 1 5 or 16. fur- - 
ther comprising an automatic repeat request (ARQ) * 
function for automatic retransmission of said RLP 
PDUs if received in error at a receiving end of said 
wireless system. 

18. A method as claimed in any of claims 12 to 17, 
wherein said step of processing comprises map- 
ping a QoS requirement to a DLC class of service 
(CoS), and separating said CoS inside the DLC 
protocol into said QoS data planes. 

19. A method as claimed in claim 18, wherein said step 
of processing further comprises adding a length 
indicator to said network layer protocol data packet. 

20. A Data Link Layer (DLL) protocol for direct support 
of a network layer protocol in the Universal Mobile 
Telecommunications System (UMTS), comprising: 

at a transmitting end of the UMTS, 

a plurality of Quality of Service (QoS) 
planes, a QoS plane for processing a QoS 
oriented data packet according to a Quality 
of Service (QoS) requirement, and to pro- 
vide a radio link control (RLC) frame; 
a subflow processing module for receiving 
a network layer protocol data packet, con- 
verting said network layer protocol data 
packet into said QoS oriented data packet, * 
and directing said QoS oriented data 
packet to one of said QoS planes accord- 
ing to QoS information in said network 
layer protocol data packet; and 
an interface between said Data Link Layer 
and a physical layer for receiving said RLC 
and transmitting same to said physical 
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layer. 

21. A DLL protocol as claimed in claim 20, wherein 
each said QoS plane comprising: 

5 

a Radio Link Control (RLC) instance for receiv- 
ing said QoS oriented data packet and generat- 
ing a RLC frame; and 

a Medium Access Control (MAC) instance for 
receiving said RLC frame over logical channels 10 
and multiplexing said RLC frames onto trans- 
port channels. 

22. A DLL protocol as claimed in claim 21 , wherein said 
RLC instance comprising a Data- RLC instance and 75 
a Control-RLC instance. 

23. A DLL protocol as claimed in claim 22, wherein said 
Data- RLC instance comprising a segmentation, 
concatenation and reframing (SCR) module for so 
receiving a plurality of said QoS oriented data 
packet, dividing same into sequence frames, and 
generating said RLC frame. 

24. A DLL protocol as claimed in claim 23. wherein said 25 
RLC frame has a variable size, said size being 
dynamically optimized based on the conditions of 
the communication link. 

25. A DLL protocol as claimed in any of claims 21 to 24, 30 
wherein said MAC instance comprising a multi- 
plexer for receiving said RLC frame and multiplex- 
ing same onto a transport channel according to 
said QoS requirement for transmission to said 
physical layer. 35 

26. A DLC protocol as claimed in any of claims 21 to 25 
further comprising a radio resource control (RRC) 
module for controlling said subflow processing 
module and the delivery of said RLC frames to said *o 
physical layer over said transport channels. 

27. A DLL protocol as claimed in claim 26, wherein said 
radio resource control (RRC) unit also for control- 
ling the mapping said QoS requirement to a class of 45 
service (CoS) inside the DLL protocol. 

28. A DLL protocol as claimed in any of claims 21 to 27, 
wherein said interface is a multiplexer for receiving 
said RLC frame from said QoS plane, and multi- so 
plexing same into said transport channels. 

29. A DLL protocol as claimed in any of claims 20 to 28, 
wherein said QoS plane is totally reconfigurable 
and accepts various types of error recovery 55 
selected according to said QoS requirement. 

30. A DLL protocol as claimed in any of claims 20 to 29, 
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further comprising identical said QoS planes and 
said subflow processing module at the receiving 
end of the UMTS. 

31 . A method for direct processing a network layer pro- 
tocol data packets for transmission over the UMTS 
wireless communication system, comprising the 
steps of: 

separating the radio link control layer of the 
wireless communication system into a plurality 
of Quality of Service (QoS) planes, a QoS 
plane for processing a QoS oriented data 
packet according to a QoS requirement, and 
generating a radio link control (RLC) frame; 
processing said network layer protocol data 
packet by converting said network layer proto- 
col data packet into said QoS oriented data 
packet and directing said QoS oriented data 
packet to one of said QoS planes according to . ' 
QoS information in said network layer protocol 
data packet; and 

forwarding said RLC frame to a physical layer 
over a transport channel. 

32. A method as claimed in claim 31 . wherein said step, 
of separating comprising: 

providing a plurality of Radio Link Control 
(RLC) instances, a RLC instance for each said 
QoS plane, said RLC instance for receiving 
said QoS oriented data packet and gene/ating- 
said RLC frame; and 

providing Medium Access Control (MAC) 
instances for receiving said RLC frames and 
multiplexing same onto said transport chan- 
nels. 

33. A method as claimed in claim 31 or 32, wherein 
said step of processing comprising mapping said 
QoS requirement to a class of service (CoS), and 
separating said CoS inside the DLL protocol into 
said QoS planes. 

34. A method as claimed in claim 33, wherein said step 
of processing further comprising dividing said QoS 
oriented data packet into smaller sequence frames 
and refraining same into said RLC frame. 

35. A method as claimed in claim 34. wherein said step 
of processing comprising adding a length indicator, 
a beginning of frame field, a sequence number 
field, and a QoS plane number to said network layer 
protocol data packet. 

36. A method as claimed in any of claims 31 to 35. 
wherein said step of generating said RLC frame 
provides a dynamic optimization of the size of said 
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RLC frame based on the conditions of the commu- 
nication link, for enhancing the quality of the air 
transmission. 

37. A method as claimed in any of claims 31 to 36. s 
comprising regulating the delivery of said RLC 
frames to said physical layer over said transport 
channel. 

38. A method as claimed in any of claims 31 to 37, w 
wherein the step of processing comprising multi- 
framing. 

39. A method as claimed in any of claims 1 2 to 1 9 or 3 1 

to 38 or the DLC protocol of any of cJaims 1 to 1 1 or 75 
the DLL protocol of any of claims 20 to 30, wherein 
said network layer protocol is Internet Protocol (IP). 
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